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Abstract. A Forensic Lucid intensional programming language has been proposed for intensional cyberforensic 
analysis. In large part, the language is based on various predecessor and codecessor Lucid dialects bound by the 
higher-order intensional logic (HOIL) that is behind them. This work formally specifies the operational aspects of 
the Forensic Lucid language and compiles a theory of its constructs using Isabelle, a proof assistant system. 



1 Introduction 

As a part of the Intensional Cyberforensics project, we define a functional-intensional programming/specification 
language, called Forensic Lucid. The language is under active design and development including its syntax, semantics, 
the corresponding compiler, run-time, and interactive "development" environments |1|2J that we refer to as General 
Intensional Programming System (GIPSY) L3J. We approach the problem using Isabelle iHJ as a proof assistant. 

Problem Statement. A lot of intensional dialects have been spawned from the functional intensional programming lan- 
guage called Lucid I5I6I7I8I9I10I1 1I12]| . Lucid (see Section [L2b itself was invented with a goal for program correctness 
verification II7I8I . While there were a number of operational semantics rules for compiler and run-time environments 
developed for all those dialects throughout the years, there was no a complete formal proof set of the rules of the 
languages. Yet another dialect of Lucid has been created to foster the research on intensional cyberforensics (see Sec- 
tion [T3]l, called Forensic Lucid, which, in a large part is a union of the syntax and operational semantics rules from 
the comprising languages with the forensic extensions. In order to be a credible tool to use, for example, in court, to 
implement relevant tools for the argumentation, the language ought to have a solid scientific base, a part of which is 
formalizing the semantics the language and proving correctness of the programs written in it. 

Proposed Solution. In this work, we propose to begin validation of the Forensic Lucid constructs with the Isabelle 
prover assistant [4} and extend it to the comprising Lucid dialects as a whole. We proceed bottom-up from "core" 
Lucid dialects such as GIPL, Lucx, and Indexical Lucid and even their smaller decompositions as well as top-down 
from Forensic Lucid to aiTive to a comprehensive set of proofs covering the dialects. 



1.1 Intensional Logics and Programming 

Definitions. Intensional programming (IP) is based on intensional (or multidimensional) logics, which, in turn, are 
based on natural language understanding aspects (such as time, belief, situation, and direction). IP brings in dimen- 
sions and context to programs (e.g. space and time in physics or chemistry). Intensional logic adds dimensions to 
logical expressions; thus, a non-intensional logic can be seen as a constant or a snapshot in all possible dimensions. 
Intensions are dimensions at which a certain statement is true or false (or has some other than a Boolean value). In- 
tensional operators are operators that allow us to navigate within these dimensions. Higher-order intensional logic 
(HOIL) is the one that couples functional programming as that of Lucid with multidimensional dataflows that the 
intensional programs can query an alter through an explicitly notion of contexts as first-class values B13I14I . 



An Example of Using Temporal Intensional Logic. Temporal intensional logic is an extension of temporal logic 
that allows to specify the time in the future or in the past. 

(1) El := it is raining here today 
Context: {place : here, time : today} 

(2) E2 '■= it was raining here /7e/ore(today) = yesterday 

(3) £3 := it is going to rain at (altitude here + 500 m) a/fer( today) = tomorrow 

Let's take Ei from (1) above. Then let us fix here to Montreal and assume it is a constant. In the month of 
February, 2008, with granularity of day, for every day, we can evaluate Ei to either true 01 false: 
Tags : 123456789... 
Values: FFTTTFFFT ... 

If one starts varying the here dimension (which could even be broken down to X, Y, Z), one gets a two-dimensional 
evaluation of Ei : 
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1.2 Lucid 

Lucid II5I6I9I7I8I is a dataflow intensional and functional programming language. In fact, it is a family of languages 
that are built upon intensional logic (which in turn can be understood as a multidimensional generalization of temporal 
logic) involving context and demand-driven parallel computation model. A program written in some Lucid dialect is 
an expression that may have subexpressions that need to be evaluated at certain context. Given the set of dimension 
D ~ {dinii} in which an expression varies, and a corresponding set of indexes or tags defined as placeholders over 
each dimension, the context is represented as a set of <dimi : tagi> mappings and each variable in Lucid, called often 
a stream, is evaluated in that defined context that may also evolve using context operators 1 1 4I15I16TT3 I. The generic 
version of Lucid, GIPL 1 11 1, defines two basic operators and # to navigate in the contexts (switch and query). The 
GIPL was the first generic programming language of all intensional languages, defined by the means of only two 
intensional operators and #. It has been proven that other intensional programming languages of the Lucid family 
can be translated into the GIPL IfTTll . Please refer to Appendix lAl for the greater details about Lucid origins, variables 
as streams, random access to streams, and the basic operators. Since the Lucid family of language thrived around 
intensional logic that makes the notion of context explicit and central, and recently, a first class value II16I13I14I15II 
that can be passed around as function parameters or as return values and have a set of operators defined upon. We 
greatly draw on this notion by formalizing our evidence and the stories as a contextual specification of the incident 
to be tested for consistency against the incident model specification. In our specification model we require more than 
just atomic context values - we need a higher-order context hierarchy to specify different level of detail of the incident 
and being able to navigate into the "depth" of such a context. A similar provision by has already been made by the 
author [17] and earlier works of Swoboda et al. in II 181 1912012 II that needs some modifications to the expressions of 
the cyberforensic context. 

Some other languages can be referred to as intensional even though they may not refer to themselves as such, 
and were born after Lucid (Lucid began in 1974). Examples include hardware-description languages (HDLs, appeared 
in 1977) where the notion of time (often the only "dimension", and usually progresses only forward), e.g. Verilog 
and VHDL. Another branch of newer languages for the becoming popular is aspect-oriented programming (AOP) 
languages, that can have a notion of context explicitly, but primarily focused on software engineering aspect of software 
evolution and maintainability. 

1.3 Cyberforensic Analysis 

Cyberforensic analysis has to do with automated or semi-automated processing of and reasoning about electronic evi- 
dence, witnesses, and other details from cybercrime incidents (involving computers, but not limited to them). Analysis 
is one of the phases in cybercrime investigation, where the others focus on evidence collection, preservation, chain 
of custody, information extraction that precede the analysis. The phases the follow the analysis are formulation of a 



report and potential prosecution, typically involving expert witnesses. There are quite a few techniques, tools (hard- 
ware and software), and methodologies have been developed for all the briefly mentioned phases of the cybercrime 
investigation. A lot of attention has been paid to the tool development for evidence collection and preservation; a few 
tools have been developed to aid "browsing" data in the confiscated storage media, log files, memory, and so on. A lot 
less number of tools have been developed for case analysis of the data, and the existing commercial packages (e.g. En- 
case or FTK) are very expensive. Even less so there are case management, event modeling, and event reconstruction, 
especially with solid formal theoretical base. The first formal approach to the cybercrime investigation was the finite- 
state automata (FSA) approach by Gladyshev et. al f2723|. The approach is complex to use and understand for non 
computer science or equivalent investigators. The aim of Forensic Lucid is to alleviate those difficulties, be sound and 
complete, expressive and usable, and provide even further usability improvement with the graphic interface that allow 
data-flow graph-based (DFG) programming that allows translation between DFGs and Lucid code for compilation and 
is implemented for Indexical Lucid in GIPSY akeady |24|, and requires forensic extensions. While Forensic Lucid is 
in the design and implementation, its solid base is being established in part with this work. The goal of Forensic Lucid 
in the cyberforensic analysis is to be able to express in a program form the encoding of the evidence, witness stories, 
and evidential statements, that can be tested against claims to see if there is a possible sequence or multiple sequences 
of events that explain a given story. This is designed to aid investigator to avoid ad-hoc conclusions and have them 
look at the possible explanations the Forensic Lucid program execution would yield and refine the investigation, as 
was shown in the works |22 23| investigators failed to analyze all the stories and their plausibility before drawing 
conclusions in the case. We do not recite the cases here due to the length limitations. 

2 Forensic Lucid 

The end goal is to define our Forensic Lucid language where its constructs concisely express cyberforensic evidence, 
which can be initial state of a case towards what we have actually observed as a final state. The implementing system 
(i.e. GIPSY) has to backtrace intermediate results in order to provide the corresponding event reconstruction path, if 
it exists. The result of the expression in its basic form is either true or false, i.e. "guilty" or "not guilty" given the 
context per explanation with the backtrace. There can be multiple backtraces, that correspond to the explanation of the 
evidence (or lack thereof). 

2.1 Properties 

We define Forensic Lucid to model the evidential statements and other expressions representing the evidence and 
observations as a higher-order context hierarchy. An execution trace of a Forensic Lucid program would expose the 
possibility of the proposed claim with the events in the middle. 

Addition of the context calculus from Lucx for operators on Lucx's context sets (union, intersection, etc.) are 
used to address to provide a collection of traces. Forensic Lucid inherits the properties of Lucx, MARFL, Objective 
Lucid, JOOIP (and their comprising dialects), where the former is for the context calculus, and the latter for the arrays 
and structural representation of data for modeling the case data structures such as events, observations, and groupings 
of the related data. 

One of the basic requirements is that the complete definition of the operational semantics of Forensic Lucid should 
be compatible with the basic Lucx and GIPL, i.e. the translation rules or equivalent are to be provided when imple- 
menting the language compiler within GIPSY, and such that the GEE can execute it with minimal changes. 
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Listing 1.1. Intensional Storyboard Expression 



While the [. . .] notation here may be confusing with respect to the notation of [dimension: tag] in Lucid 
and more specifically in Lucx II13I25I . it is in fact a simple syntactical extension to allow higher-level groups of 
contexts where this syntactical sugar is later translated to the baseline context constructs. The tentative notation of 
{[...],...,[...]} implies a notion similar to the notion of the "context set" in II13I25I except with the syntactical 
sugar mentioned earlier where we allow syntactical grouping of properties, observations, observation sequences, and 
evidential statements as our context sets. 

2.2 Transition Function 

A transition function determines how the context of evaluation changes during computation. A general issue exists that 
we have to address is that the transition function y/ is problem-specific. In the FSA approach, the transition function is 
the labeled graph itself. In the first prototype, we follow the graph to model our Forensic Lucid equivalent. In general. 
Lucid has already basic operators to navigate and switch from one context to another, which represent the basic 
transition functions in themselves (the intensional operators such as 0, #, iseod, first, next, fby, wvr, upon, and 
asa as well as their inverse operator^. However, a specific problem being modeled requires more specific transition 
function than just plain intensional operators. In this case the transition function is a Forensic Lucid function where 
the matching state transition modeled through a sequence of intensional operators. In fact, the forensic operators are 
just pre-defined functions that rely on traditional and inverse Lucid operators as well as context switching operators 
that achieve something similar to the transitions in M22I23I . In fact, the intensional operators of Lucid represent the 
basic building blocks for x^f and 

2.3 Primitive Operators 

The basic set of the classic intensional operators is extended with the similar operators, but inverted in one of their 
aspects: either negation of trueness or reverse of direction of navigation. Here we provide an informal definition 
followed by their formal counterpart of these operators alongside with the classical ones (to remind the reader what 
they do and enlighten the unaware reader). The reverse operators have a restriction that they must work on the bounded 
streams at the positive infinity. This is not a stringent limitation as the our contexts of observations and evidence in 
this work are always finite, so they all have the beginning and the end. What we need is an ability to go back in the 
stream and, perhaps, negate in it with classical-like operators, but reversed. 

The operators are defined below to give a complete picture. The classical operators first, next, fby, wvr, upon, 
and ASA were previously defined in lITTI and earlier. The other complimentary, inverse, and negation operators were 
defined and revised from f26\. In this list of operators, especially the reverse ones, we make an important assumption 
that the streams we are working with are finite, which is sufficient for our tasks. Thus, our streams of context values 
can be bound between bod and eod and contain a finite tag set of elements is used as a context type. For summary of 
the application of the just defined operators' examples, please refer to AppendixlB] 

Following the steps in 1 1 1 1, we further represent the definition of the operators via @ and #. Again, there is a mix 
of classical operators that were previously defined in [[llj, such as first, next, fby, wvr, upon, and asa as well as 
the new operators from this work. The collection of the translated operators denoted in monospaced font, while we 
provide their equivalence to the original Lucid operators, denoted as small caps. 

The primitive operators are founding blocks to construct more complex case-specific functions that represent a 
particular investigation case as well as more complex so-called /orens/c operators. 

- A stream of first elements of stream X: 
firstX = {xQ,XQ,...,xo,...) 

first X=X@0 (1) 

- A stream of second elements of stream X: 

SECOND X = {xi,Xi,...,Xi,...) = FIRST NEXT X 
' Defined further. 



A stream of last elements of stream X: 

LAST X = {Xfi^Xfi^ ...,X/j, ...) 

This definition of the last operator reUes on the earlier stated assumption that our streams can be explicitly finite 
for the language we are developing. This affects the follow up operators that rely in that fact just as well. It is also 
important to note that the last operator in our design does not return eod all the time on the finite stream due to 
lack of usefulness for such a value; instead it returns the element of the stream just before the eod. 

last X=X@(#@(#iseod(#)-l)) (2) 
A stream of elements one before the last one of stream Z: 

PRELASTX = (x„_i,X„_i, ...,X„-l, ...) = LAST PREVX 

A stream of elements of stream X other than the first: 

NEXTX = (X1,X2,...,X,+1,...) 

next X=X@(#+1) (3) 
A stream of elements of stream X other than the last: 

PREVX = {Xn-\ Xi+\,Xi,Xi-l,...) 



prev X=X@(#-1) (4) 



First element of X followed by all of F: 
Xfb^Y = {xQ,yQ,yi,...,yi-i,...) 



Z fby F = if# = OthenXelsey@(#- 1) (5) 
= if isbodX thenX else prev Y 

First element of X preceded by all of Y: 
X pbyF = (yo,3'i,...,3',-i, •••,>'«, xo) 



X pby y = if iseod#thenXelsey@(#+l) (6) 
= if iseod Y tlienX else next Y 



Stream of negated arithmetic values of X: 

NEGX = (-Xo,-Xi,-X2,...,-Xi+i,...) 



Stream of inverted truth values of X: 
NOT X = (!xo, !x2, ...) 



neg X = -X (7) 



not X=iiX tlien \X else X (8) 



A logical AND stream of truth values of X and Y: 

X AND Y = (xo&&)'0,^l&&)'l5^2&&)'2,-",^(+l&&3'i+l) 



X and y = X&&.Y (9) 



A logical OR stream of truth values of X and Y: 

X oRy = (xo||)'o,^i|bi,^2|b2,"-,^i+ilbi+i,.-) 



X or y = x||y 



(10) 



- A logical XOR stream of truth values of X and Y: 
X xorF = (xoOyo.xi ®yi,x2®y2,—,xi+i®yi+i,...) 



X xor y=not((XandF)ornot(Xory)) (11) 

- WVR Stands for whenever. WVR chooses from its left-hand- side operand only values in the current dimension where 
the right-hand- side evaluates to true. 
X WVR Y = 

if FIRST y ^ 

then X FBY (next X wvr next Y) 
else (next X wvr next Y) 



X wvr y = X@T where (12) 
T = UfhjU@{T + l) 
f/ = if y then # else next U 

end 

- RWVR Stands for retreat whenever, rwvr chooses from its left-hand- side operand backwards only values in the 
current dimension where the right-hand- side evaluates to true. 
X RWVR y = 
if LAST y 

then X PBY (PREV X rwvr prev Y) 
else (prev X rwvr prev Y) 



X rwvr y = X@T where (13) 
7' = f/pbyf/@(r-l) 
f/ = if y then # else prev U 

end 

- NWVR stands for not whenever, nwvr chooses from its left-hand- side operand only values in the current dimension 
where the right-hand-side evaluates io false. 
X NWVR Y = X wvr not y 
if FIRST y == 

then X FBY (next X nwvr next Y) 
else (next X nwvr next Y) 



X nwvr y = X@T where (14) 

r = t/fbyt/@(r-M) 

f/ = if y == then # else next U 

end 

- NRWVR stands for do not retreat whenever, nrwvr chooses from its left-hand- side operand backwards only values 
in the current dimension where the right-hand- side evaluates io false. 
X NRWVR Y = X rwvr not y = 

if LASTy ==0 

then X PBY (prev X nrwvr prev Y) 
else (prev X nrwvr prev Y) 



X rnwvr y =X@7' where (15) 

r = f/pby{/@(r-i) 

£/ = if 7 == then # else prev U 

end 

ASA Stands for as soon as. asa returns the value of its left-hand- side as a first point in that stream as soon as the 
right-hand- side evaluates to true. 

X ASA Y = FIRST {X WVR Y) 

X asa F = first {X wvr Y) (16) 

ALA (other suggested name is rasa) stands for as late as (or reverse of a soon as), ala returns the value of its 
left-hand-side as the last point in that stream when the right-hand- side evaluates to true for the last time. 

X ALA Y = last {X WVR Y) 

X ala 7 = last {X rwvr Y) (17) 

NASA Stands for not as soon as. nasa returns the value of its left-hand- side as a first point in that stream as soon 
as the right-hand-side evaluates to false. 

X NASA Y = FIRST {X NWVR Y) 

X nasa F = first {X nwvr F) (18) 

NALA (other suggested name is nrasa) stands for not as late as (or reverse of not a soon as), nala returns the 
value of its left-hand- side as the last point in that stream when the right-hand- side evaluates to false for the last 
time. 

X NALA F = LAST {X NWVR F) 

X nala Y = last {X nrwvr F) (19) 

UPON stands for advances upon. Unlike asa, upon switches context of its left-hand- side operand if the right-hand 
side is true. 

X UPON Y = X FBY ( 
if FIRST F ^ 

then (next X upon next F) 
else {X UPON next F)) 



X upon F = X@W where (20) 
W = f by (if F then {W + l) else W) 

end 

- RUPON stands for retreats upon, rupon switches context backwards of its left-hand- side operand if the right-hand 

side is true. 
X rupon Y = X pby ( 
if last F ^0 

then (prev X rupon prev F) 
else {X RUPON prev F)) 



X rupon F 



= X@W where 

W = Opby (ifFthen(W- 
end 



l)elseW) 



(21) 



- NUPON Stands for not advances upon or rather advances otherwise, nupdn switches context of its left-hand-side 
operand if the right-hand side is false. 

X NUPDN Y —X UPON NOT Y —X FBY ( 
if FIRST Y —— 

then (next X nupdn next Y) 
else {X nupon next Y)) 

X nupon Y = X@W where (22) 
W = f by (if 7 then (W+l) else W) 

end 

- NRUPON stands for not retreats upon, nrupdn switches context backwards of its left-hand-side operand if the 
right-hand side is false. 

X NRUPDN Y = X RUPDN NOT Y —X PBY ( 
if LAST Y == 
then (PREVX NRUPDN PREV Y) 

else {X NRUPON prev Y)) 

X nrupon Y = X@W where (23) 
= pby (if F == then (W - 1) else W) 

end 



2.4 Forensic Operators 

The operators presented here are based on the discussion of the combination function and others that form more- 
than-primitive operations to support the required implementation. The discussed earlier combO operator needs to be 
realized in the general manner for combining analogies of MPRs, which in our case are higher-level contexts, in the 
new language's dimension types. 

- combine corresponds to the comb function as originally described by Gladyshev in ll22ll . It is defined in Listing [L2l 
It is a preliminary context-enhanced version. 

/* * 

* Append given e to each element 

* of a given stream e under the 

* context of d . 

* 

* @return the resulting combined stream 
*/ 

combine ( s , e , d) = 
if iseod s then eod ; 

else (first s fby.d e) fby . d combine ( next s, e, d) ; 
fi 

Listing 1.2. The combine Operator 

- product tentatively corresponds to the cross-product 1221 of contexts. It is defined in Listing [T3] 

The translated examples show recursion that we are not prepared to deal with in the current Lucid semantics, and 
will address that in the future work. The two illustrated operators are the first of the a few more to follow in the final 
language prototype. 
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product ( si , s2 , d) 






if iseod s2 then 


eod ; 




else combine ( si , 
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product(sl, next s2 ) ; 


fi 







Listing 1.3. The prodtict Operator 



2.5 Operational Semantics 

As previously mentioned, the operational semantics of Forensic Lucid for the large part is viewed as a composition of 
the semantic rules of Indexical Lucid, Objective Lucid, and Lucx along with the new operators and definitions. Here 
we list the existing combined semantic definitions to be used the new language, specifically extracts of operational 
semantics from GIPL fTTl, and Lucx (13] are in Figure [T] and Figure ^respectively. The explanation of the rules and 
the notation are given in great detail in the cited works and are trimmed in this article. For convenience of the reader 
they are recited here to a degree. The new rules of the operational semantics of Forensic Lucid cover the newly defined 
operators primarily, including the reverse and logical stream operators as well as forensic-specific operators. We use 
the same notation as the referenced languages to maintain consistency in defining our rules. 

In the implementing system, GIPSY, the GIPL is the generic counterpart of all the Lucid programming languages. 
Like Indexical Lucid, which it is derived from, it has only the two standard intensional operators: E @ C for evaluating 
an expression E in context C, and #d for determining the position in dimension d of the current context of evaluation 
in the context space IITTI . SIPLs are Lucid dialects (Specific Intensional Programming Languages) with their own 
attributes and objectives. Theoretically, all SIPLs can be translated into the GIPL All the SIPLs conservatively 
extend the GIPL syntactically and semantically. The remainder of this section presents a relevant piece of Lucx as 
a conservative extension to GIPL. The semantics of GIPL is presented in Figure [T] The excerpt of semantic rules of 
Lucx are then presented as a conservative extension to GIPL in Figure [3] Following is the description of the GIPL 
semantic rules as presented in LIU : 

^h£:v 

tells that under the definition environment '3, expression E would evaluate to value v. 

specifies that in the definition environment 2i, and in the evaluation context (sometimes also referred to as a point 
in the context space), expression E evaluates to v. The definition environment ^ retains the definitions of all of the 
identifiers that appear in a Lucid program, as created with the semantic rules 13-16 in Figure[T] It is therefore a partial 
function 

^ : Id ^ IdEntry 

where Id is the set of all possible identifiers and IdEntry, has five possible kinds of value, one for each of the kinds 
of identifier: 1. Dimensions define the coordinate pairs, in which one can navigate with the # and @ operators. Their 
IdEntry is simply (dim). 2. Constants are external entities that provide a single value, regardless of the context 
of evaluation. Examples are integers and Boolean values. Their IdEntry is (const, c), where c is the value of the 
constant. 3. Data operators are external entities that provide memoryless functions. Examples are the arithmetic and 
Boolean functions. The constants and data operators are said to define the basic algebra of the language. Their IdEntry 
is (op,/), where / is the function itself. 4. Variables carry the multidimensional streams. Their IdEntry is (varjE), 
where E is the Lucid expression defining the variable. It should be noted that this semantics makes the assumption 
that all variable names are unique. This constraint is easy to overcome by performing compile-time renaming or using 
a nesting level environment scope when needed. 5. Functions are non-recursive GIPL user-defined functions. Their 
IdEntry is {tunc, idi,E), where the id, are the formal parameters to the function and E is the body of the function. In 
this paper we do not discuss the semantics of recursive functions. 



_ &{id) = (const,c) 

^""^ ■ &,^^id:c ^^^^ 
. ^(^-c/) = (dim) 

^•"•^ • ^,^hW:W ^^^^ 
_ ^(irf) = (func,/rfi,£) 

^"•^ • ^,^hirf:W ^^^^ 

^(iW) = (var,£) ^,^h£:v 
^"•^ ■ &,^^id:v ^^^^ 

^, h £ : irf &{id) = (op, /) i^, ^ h : v,- ^^^^ 



Met 



g',^h£(£i,...,£„):/(vi,...,v„) 

'\-E:id &{id) = {t\mc,idi,E') E'[idi ^ Ej] : v 

S',^\-E{Ei,...,E„):v 



i/.,y' I Q : '/'.-/'' '/' ,:y' E : v 
9,^'^E where Q : v 



(30) 



^,^\-E:true ^, ^ h £" : v' 

■ S',^\-±fE then £' else £" : v' 

^ &,.^hE -.false &,.^hE":v" 

■ i^, ^ h if £ then £' else £" : v" ^^^^ 

i^(/rf) = (dim) 

&,^^E':id Si{id) = {A±m) &,^^E":v" ^^[id ^ v"]\- E : v 

■ Si,^\-E@E' E":v *■ -* 



(35) 



■ ^, ^ I- dimension W : S>-\[id^ (dim)], [id ^0] ^^^^ 
' &,^\-id = E : ^t[Wh-» (var,£;)],^ ^^'^^ 

■ &,^hid{idu---,idn)=E : S)t[id^ {±unc,idi,E)],^ ^^^^ 

Fig. 1. GIPL Semantics 

. 9{E.id) = (dim) 
• &,^hE.id:id.id 

Fig. 2. Higher-Order Context Dot Operator 
The evaluation context which is changed when the operator is evaluated, or a dimension is declared in a 
where clause, associates a tag (i.e. an index) to each relevant dimension. It is, therefore, a partial function 



,^ : Id ^ N 



Each type of identifiers can only be used in the appropriate situations. Identifiers of type op, f unc, and dim evaluate to 
themselves (Figure[Tl rules I25I26I27I) . Constant identifiers (const) evaluate to the corresponding constant (Figure[T] 
rulel24li. Function calls, resolved by the Efct rule (Figure[T] rule[30ll. require the renaming of the formal parameters into 
the actual parameters (as represented by E'[idi ^ Ei]). The function £P' = £P'\'[id t-^ v"] specifies that ^'(x) is v" if 
X = id, and ^(x) otherwise. The rule for the where clause, (Figure[Tl rule[35]), which corresponds to the syntactic 
expression E where Q, evaluates E using the definitions Q therein. The additions to the definition environment 
and context of evaluation ^ made by the Q rules (Figure [T] rules I36I37I38I ) are local to the current where clause. 
This is represented by the fact that the rule returns neither ^ nor The Qdim rule adds a dimension to the 
definition environment and, as a convention, adds this dimension to the context of evaluation with tag (Figure [T] 
rule[36l). The Qj^ and Qaj simply add variable and function identifiers along with their definition to the definition 
environment (Figure [T] rules l37l38] ). 

As a conservative extension to GIPL, Lucx's semantics introduces the notion of context as a building block into 
the semantic rules, i.e. context as a first-class value, as described by the rules in Figure[3] In Lucx, semantic rule l42l 
(Figure O creates a context as a semantic item and returns it as a context that can then be used by rule |43] to 
navigate to this context by making it override the current context. GIPL's semantic rule|29]is still valid for the definition 
of the context operators, where the actual parameters evaluate to values v; that are contexts The semantic rulelTTI 
expresses that the # symbol evaluates to the current context. When used as a parameter to the context calculus operators, 
this allows for the generation of contexts relative to the current context of evaluation. 

E#(cxt) : ^^^^ 

21,0^^ Ed. : idj Si{idj) = (dim) 

&,.&>^ Ej. : Vj = ^otK ^ vilt. . -tK ^ v„] 

l^CO„StrUCtiO„(CXt) : OJ^C^^ ; £. ; £ . _ . ; £. ] ; ^42) 



2,&>^E':&>' S),3fi\&>'^E:v 
Sj,&>VE@ E' w 

Fig. 3. Conservative Semantic Rules Introduced by Lucx 



Eat(cxt) : S,,&>VE@E':v ^"^^^ 



3 Conclusion 

While the list of Isabelle's proofs is incomplete at the time of the writing of this manuscript some formalization in 
Isabelle took place, and the work on them is currently on-going. 

3.1 Results 

Due to a non-standard nature of the Lucid language (as opposed to standard imperative languages), it takes some time 
to understand the full scope of some of its details and model them. This complicates a way to model its operators, 
expressions, overall meaning in Isabelle. This fact resulted in several trials and attempts to approach the language, 
from fairly complex to fairly basic - plain integers and pipelined processing and basic index support. They are not 
fully complete, but some of the basic properties are modeled and proven; please refer to the Isabelle sources for details 
(once completed it is planned to be released as a part of the Archive of Formal Proofs at [27 ]). 

- The IntegerLucid Isabelle file is the most developed out of all as far as definition and exploitation of intensional 
operators of classical Lucid concerned. It is called "integer" because all the streams and dimensions and all opera- 
tors around them play with integers, natural numbers, and in rarer cases Booleans. There are no identifiers in there. 
The Isabelle file contains three theories: OriginalLucidOperators, LucidOperators, and IntegerLucid. 
The first models classical Lucid operators as pipelined dataflows. The second adds up some index support and 
proves equivalence to the first definitions. The latter provides new definitions of the intensional operators through 
Q and #, defines meaning functions, propositions, and lemmas from ifTTll . Integer Lucid proves the example for A' 
@.d 2 = 44 for the at(). 



- The BasicLucid theory is currently the second one derived to support Lucid definitions. It is an extension of 
IntegerLucid by adding identifiers, asa and upon are in this theory. 

- The LucidSemaiiticRules theory is meant to have the meaning of complete semantic rules and proven, but it 
only has a definition of a Hoare tuple |[28l and a meaning function for it. 

- The CommonLucidTypes theory is used by all (most) theories and defines some common types used by most 1291 . 

- ForensicLucid . thy, GIPL . thy, IndexicalLucid. thy, JLucid . thy, JDDIP .thy, Lucx . thy, Dbj ect iveLucid . th.y\ 
are the theories under current development with some results from the above. The completed work wiU have a 
complete list of the files publicly available and submitted to the AfP [271 . 

3.2 Future Work 

The near-future work will consist primarily of the following items: 

- Complete semantics of all the mentioned Lucid dialects and their formalization with Isabelle. 

- Augment the language specification to include the Depmster-Shafer theory Ii30i3 1 1 of evidence to allow weights 
for claims, credibility, beUef, and plausibility parameters. 

- Prove semantic rules involving intensional data warehouse. 

- Implementation of the Forensic Lucid compiler, run-time and interactive development environments. 

4 Acknowledgments 

This research and development work was funded in part by NSERC and the Faculty of Engineering and Computer 
Science of Concordia University, Montreal, Canada. Thanks to Drs. Mourad Debbabi, Patrice Chalin, Peter Grogono 
on valuable suggestions used in this work. 

References 

1. Mokhov, S.: Intensional Forensics - the Use of Intensional Logic in Cyberforensics. Technical report, Concordia Institute for 
Information Systems Engineering, Concordia University, Montreal, Canada (lanuary 2007) ENGR6991 Technical Report. 

2. Mokhov, S.: Intensional Cyberforensics - a PhD Proposal. Department of Computer Science and Software Engineering, 
Concordia University, Montreal, Canada (December 2007) 

3. The GIPSY Research and Development Group: The General Intensional Programming System (GIPSY) project. 
Department of Computer Science and Software Engineering, Concordia University, Montreal, Canada (2002-2008) 
http : //newton. cs . concordia. ca/~gipsy/ , last viewed April 2008. 

4. Paulson, L.C., Nipkow, T: Isabelle: A generic proof assistant. University of Cambridge and Technical University of Munich 
(2007) http : // isabelle . in . turn . de/ last viewed: December 2007. 

5. Wadge, W., Ashcroft, E.: Lucid, the Dataflow Programming Language. Academic Press, London (1985) 

6. Edward Ashcroft and Anthony Faustini and Raganswamy lagannathan and William Wadge: Multidimensional, Declarative 
Programming. Oxford University Press, London (1995) 

7. Ashcroft, E.A., Wadge, W.W.: Lucid - A Formal System for Writing and Proving Programs. Volume 5., SIAM I. Comput. no. 
3 (1976) 

8. Ashcroft, E.A., Wadge, W.W.: Erratum: Lucid - A Formal System for Writing and Proving Programs. Volume 6(1):200., SIAM 
I. Comput. (1977) 

9. Ashcroft, E.A., Wadge, W.W.: Lucid, a nonprocedural language with iteration. Communication of the ACM 20(7) (July 1977) 
519-526 

10. Gagne, J.R., Plaice, J.: Demand-Driven Real-Time Computing, World Scientific (September 1999) 

11. Paquet, J.: Scientific Intensional Programming. PhD thesis. Department of Computer Science, Laval University, Sainte-Foy, 
Canada (1999) 

12. Wan, K., Alagar, V, Paquet, J.: A Context theory for Intensional Programming. In: Workshop on Context Representation and 
Reasoning (CRR05), Paris, France. (July 2005) 

13. Wan, K.: Lucx: Lucid Enriched with Context. PhD thesis. Department of Computer Science and Software Engineering, 
Concordia University, Montreal, Canada (2006) 



14. Paquet, J., Mokhov, S.A., Tong, X.: Design and implementation of context calculus in the GIPSY environment. In: Proceedings 
of the 32nd Annual IEEE International Computer Software and Applications Conference (COMPSAC), Turku, Finland, IEEE 
Computer Society (July 2008) 1278-1283 

15. Tong, X.: Design and implementation of context calculus in the GIPSY. Master's thesis. Department of Computer Science and 
Software Engineering, Concordia University, Montreal, Canada (April 2008) 

16. Wan, K., Alagar, V., Paquet, J.: Lucx: Lucid Enriched with Context. In: Proceedings of the 2005 International Conference on 
Programming Languages and Compilers (PLC 2005), Las Vegas, USA, CSREA Press (June 2005) 48-14 

17. Mokhov, S.A.: Towards syntax and semantics of hierarchical contexts in multimedia processing applications using MARFL. 
In: Proceedings of the 32nd Annual IEEE International Computer Software and Applications Conference (COMPSAC), Turku, 
Finland, IEEE Computer Society (July 2008) 1288-1294 

18. Swoboda, P.: A Formalisation and Implementation of Distributed Intensional Programming. PhD thesis. The University of 
New South Wales, Sydney, Australia (2004) 

19. Swoboda, P., Wadge, W.W.: Vmake, ISE, and IRCS: General tools for the intensionalization of software systems. In Gergat- 
soulis, M., Rondogiannis, P., eds.: Intensional Programming II, World-Scientific (2000) 

20. Swoboda, P., Plaice, J.: A new approach to distributed context-aware computing. In Ferscha, A., Hoertner, H., Kotsis, G., eds.: 
Advances in Pervasive Computing, Austrian Computer Society (2004) ISBN 3-85403-176-9. 

21. Swoboda, P., Plaice, J.: An active functional intensional database. In Galindo, R, ed.: Advances in Pervasive Computing, 
Springer (2004) 56-65 LNCS 3180. 

22. Gladyshev, P., Patel, A.: Finite state machine approach to digital event reconstruction. In: Digital Investigation Journal. 
Volume 2. (2004) 

23. Gladyshev, P.: Finite state machine analysis of a blackmail investigation. In: International Journal of Digital Evidence, 
Technical and Security Risk Services, Sprint 2005, Volume 4, Issue 1 (2005) 

24. Ding, Y.M.: Bi-directional translation between data-flow graphs and Lucid programs in the GIPSY environment. Master's 
thesis. Department of Computer Science and Software Engineering, Concordia University, Montreal, Canada (2004) 

25. Tong, X., Paquet, J., Mokhov, S.A.: Context Calculus in the GIPSY. Unpublished (2007) 

26. Mokhov, S.A., Paquet, J., Debbabi, M.: Designing a language for intensional cyberforensic analysis. Unpublished (2007) 

27. Klein, G., Nipkow, T, Paulson, L.C.: The archive of formal proofs. SourceForge.net (2008) 
http : / /afp ■ sourcef orge .net/j last viewed: April 2008. 

28. Moeller, A.: Program Verification with Hoare Logic. Technical report. University of Aarhus (2004) 
http : //www.brics .dk/~amoeller/talks/hoare .pdf 

29. Mokhov, S.A., Paquet, J., Tong, X.: Hybrid intensional-imperative type system for intensional logic support in GIPSY. Sub- 
mitted for publication at LPAR'08 (2008) 

30. Shafer, G.: The Mathematical Theory of Evidence. Princeton University Press (1976) 

31. Haenni, R., Kohlas, J., Lehmann, N.: Probabilistic argumentation systems. Technical report. Institute of Informatics, University 
of Fribourg, Fribourg, Switzerland (October 1999) 

32. Kahn, G.: The semantics of a simple language for parallel processing. In: Proceedings of the IFIP Congress '74, Amsterdam, 
Elsevier North-Holland (1974) 471-475 

33. Kahn, G., MacQueen, D.B.: Coroutines and networks of parallel processes. In: Proceedings of the IFIP Congress '77, Ams- 
terdam, Elsevier North-Holland (1977) 993-998 

34. Landin, P.J.: The next 700 programming languages. Communications of the ACM 9(3) (1966) 157-166 



A Lucid Axioms, Theorems, and Proofs 

Here we present and extend the notion of the formalisms from Paquet ifTTIl and extend them on to the present work. 
A.l Streaming and Basic Operators 

The origins of Lucid date back to 1974. At that time, Ashcroft and Wadge were working on a purely declarative 
language, in which iterative algorithms could be expressed naturally, which eventually resulted in |i9J. Their work 
fits into the broad area of research into program semantics and verification. It would later turn out that their work is 
also relevant to the dataflow networks and coroutines of Kahn and MacQueen 13213311 . In the original Lucid (whose 




operators are in this font), streams were defined in a pipelined manner, with two separate definitions: one for the 
initial element, and another one for the subsequent elements. For example, the equations 

firstX = 
nextZ =X + l 

define variable X to be a stream, such that 

XQ = 



In other words. 



Similarly, the equations 



Xi+l =Xi+l 

= (0,0,0,. ..,0,...) 

X = (jco,jci,...,jc,-,...) = (0, 1,...,/,...) 



firstX = X 

nextF =Y+nextX 



define variable Y to be the running sum of X, i.e. 

yo = -^0 
yi+i = yi+Xi+i 

In other words, 

/(/+1) 



Y = (yo,yu...,yi,...)^{0,l 

It soon became clear that a "new" operator at the time, f by (followed by) can be used to define such typical situations. 
Hence, the above two variables could be defined as follows: 

X = OfbyX+1 

Y = X FBYF+ nextX 

As a result, we can summarize the three basic operators of the original Lucid. 

Definition 1 IfX — {xo,xi,. . . ,Xi, . . .) and Y {yi),y\ ,yi, ■ ■ ■), then 

(1) firstX =^ (jt:o,Xo,...,Xo,...) 

def 

(2) nextX = (xi,X2,...,x,+i,...) 

def 

(3) XFBYy = {x(i,y(i,yi,...,yi_i,...) 



Here parallels can be drawn to the list operations, where first corresponds to head, next corresponds to tail, 
and fby corresponds to cons. When these operators are combined with Landin's ISWIM f34l {If You See What I 
Mean), essentially typed A-calculus with syntactic sugar, it becomes possible to define complete Lucid programs. The 
following three derived operators have turned out to be very useful (we will use them later in the text): 



Definition 2 

def 

(1) X WVR Y = if FIRST Y thenX fby ( nextX wvr next Y) 

else ( NEXT X WVR NEXT F) 

Hpf 

(2) XaSA}' = first (X WVR F) 

def 

(3) X UPON Y = X FBY {if firstF then ( nextX upon nextF) 

else{ X upon nextF)) 



Where wvr stands for whenever, asa stands for as soon as and upon stands for advances upon. 
A.2 Random Access to Streams 

With the original Lucid operators, one could only define programs with pipelined dataflows, i.e. in which the {i + l)-th 
element in a stream is only computed once the i-th element has been computed. This situation is potentially wasteful of 
resources, since the i-th element might not necessarily be required. More importantly, it only aUows sequential access 
into streams. 

By taking a different approach, it is possible to have random access into streams, using an index # corresponding 
to the current position, the current context of evaluation. No longer are we manipulating infinite extensions (streams), 
rather we are defining computation according to a context (here a single integer). We have set out on the road to 
intensional programming. We redefine all original Lucid operators in terms of the operators # and @: 



Definition 3 

(1) # =0fby(#+1) 

(2) X @Y = ifY = then firstX 

else (nextX) (5(7-1) 



Further, we give definitions for the original operators using these two basehne operators. In so doing, we will use the 
following axioms. 



Axiom 1 Let i> 0. 



(1 
(2 
(3 
(4 
(5 
(6 
(7 
(8 
(9 



[c]i = c 

[X + c]i = [X]i + c 

[ FIRST X]; = [X]o 
[nextX]/ = [X]i+i 
[X FBY Y]q = [X]o 

[Xfby Y]i+,^[Y]i 

if true then [X]i else [Y]j — [X]j 

if false then [X]i else [Y]i = [Y]i 

[ifC thenX elseY]i = if [C]i then [X]i else [Y]i 



Prior giving the re-definitions of the standard Lucid operators, we show some basic properties of @ and #. We will 
use throughout the discussion here [X]i instead of jc,, as it allows for greater readability. Furthermore, we will, as is 
standard, write X = Y whenever we have 

(V/:/>0:[X],-[y];) 



Proposition 1. Let i > 0. 



(1) [#]<■ = 

(2) [X @Y]i^[X],y. 



Proof 

(!) Proof by induction over 
Base step (/ = 0). 



[#]o 



[0 FBY (#- 

[0]o 




l)]c 



Induction step (i = k+ 1). Suppose (V/ : i <k: [#],■ = /). 



[0 FBY (# - 

k+1 



+1 



Hence (V/ : / > : [#],■ = /)■ 

(2) Let / > 0. We will prove by induction over yj that yt >0 
Base step (j,- = 0). 



[X®Y]i=[XU, 



Defn.[3]l 
Axiom[T]5 
Axiom[T] 1 



Defn.Ol 
Axiom[T]6 
Axiom[T]2 
Ind. Hyp. 



[X@Y]i = [if y ==Othen firstX else ( nextX) (F- 1)]; Defn.[3l2 
= if [y = 0]; then [first X]; else [(nextX) (y- I)]; Axiom[I]9 
= if [Y]i = then [first xj; else [( nextX) (y- I)]; Axiom[T]2 
= [ FIRST X]i Axiom[T]7 
= [X]o Axiom[T]3 
= [^][F], Hypothesis 



Induction step (y,- = k+ 1). Suppose (V/ ■.i<k: [#],■ — i). 



[X@Y]i = [if y^Othen firstX else ( nextX) (§ (F - 1)]; Defn.[3l2 

= if [y = 0],- then [first X]i else [(nextX) (F- 1)],- Axiom[T]9 

= if [y]; = then [first X],- else [( nextX) (Y - 1% Axiom[T]2 

= [( nextX) (F- 1)],- Axiom[T]8 

= [ NEXTX][y_i]. Ind. Hyp. 

= [ NEXTX][y]._i Axiom[T]2 

= [X\y],-i+i Axiom[T]4 

= [X][Y], Arith. 

Hence (V/ : / > : [Y]i > => {[X ® Y]i = [X] [yy))- □ 



Definition 4 



(1) firsts =X @0 

(2) nextX 

(3) XfhyY = if #=Q thenX elseY @{#-\) 

(4) XwvrF =*^XOr 

where 

(4.1) r = f/fbyf/ (9(r + l) 

(4.2) U=ifYthen#elsenextU 
end 

Hpf 

(5) XasaF = first (X wvr F) 

(6) Xu.poiLY=X@W 

where 

(6.1) W = Ofby i/y then(W+ 1) elseW 

end 



The advantage of these new definitions is that they do not use any form of recursive function definitions. Rather, all of 
the definitions are iterative, and in practice, more easily implemented in an efficient manner. We prove below that the 
new definitions are equivalent to the old ones. 



Proposition 2. firstX= first X. 



Proof Let / > 0. Then 



[firsts],- = [X®0]i Defn.Hl 

= [X][o]. Prop.[I]2 

= [X]o Axiom[I]l 

= [ first X],- Axiom[T]3 

Hence firsts = firstX. □ 



Proposition 3. next X = next X. 



Proof Let / > 0. Then 

[nextX]i = [X® {#+!)]. 

= [X]i+i 

~ [ NEXTX]; 

Hence next X = next X. 



Defn.|4]2 
Prop.[I]2 
Axiom[T]2 
Prop. [Hi 
Axiom[T]4 



Proposition 4. X f by Y = X fby Y. 



Proof Proof by induction over i. 
Base step (/ = 0). 



[Xfbyyjo = [if # = OtlienXelsey(§ (#-l)]o 

= if [# = 0]o then [X]o else [y (#- l)]o 
= if [#]o = then [X]q else [F (# - l)]o 
= if = then [X]q else [F (# - 1 )]o 

-Wo 



Induction step (i = k+l). 



[XfbyFU. 



+1 



= [if # = OthenXelsey(§(#-l)]^^j 
= if [# = 0]k+i then [X]^+i else [Y @ {# - 
= if [#]^+i = then [X]^+i else [F ® (# - l)]i+i 
if /t + 1 = then [X]k+i else [F (# - l)]^+i 
^ [Y®{#-iy 

- [y].. 

= [X FBY F] 



[#]*+! -1 



Defn.HS 

Axiom[T]9 

Defn.[I]2 

Prop.ffll 

Axiom[I]7 

Axiom[T]5 



Defn.|4l3 

Axiom[T]9 

Axiom[T]l 

Prop. [Hi 

Axiom[T]8 

Prop.[I]2 

Axiom[T]2 

Prop. [Hi 

Axiom[T]6 



Hence (V/ :i>0:[X fby Y]i = [X fby F],). Hence fby = fby . □ 
The proof for wvr is more complicated, as it requires relating an iterative definition to a recursive definition. We will 
therefore need four lemmas that refer to variables T and U in the text in Definitions |4]4.1 and|4]4.2. In addition, we 
must define the rank of a Boolean stream. Finally, we will have to introduce another set of axioms, that allow us to 
compare two entire streams, as opposed to particular elements in the two streams. 



Axiom 2 Let i> 0. 



(2) [X']o = [Xy 

(3) firstX' = [X]i 

(4) nextX'=X'+i 

(5) NEXT {X fbyF) =F 

(6) ( firstX) fbyF —X FBY y 

(7) if true thenX elseY =X 

(8) if false thenX elseY = Y 



Definition 5 Let Y be a Boolean stream. 



def 



(1) rank{-\,Y) = -1 



def 

(2) ranfc(/ + = min{A: : k > rank{i,Y) : [Y]i; = true} 



Further, we write r,- for rank(!,F). 



Lemma 1. (V/: / > -1 : (Vj : n <j< n+i : X-'' wvr F-'' = wvay'+i))- 



Proof Let i> — I. Proof by downwards induction over j. Note that r, < r,+i. 
Base step (j ^ n+i). 

wvrF'"'+i =^'■'+1 WVRy'+l 

Induction step (j = k—l, j > r,). 

X''-'^ wvRy^-i = if FIRST y^^-i thenX^-i fbyX* wvrF*^ 

elseX^^wvR Y'^ 
= if [y]A._i thenX''-^ fby X'' vvrY'' 
elseX'' WVR Y'' 

= X* WVR 

= x'''+i wvRy'+i 

Hence, (V/: /> -1 : (V; : n <j< r,+i : X-'' wvr F' = wvRy'+i))- 



Identity 

Defn.|2]l 

Axiom|2l3 

Axiom|2l8 
Ind. Hyp. 



□ 



Lemma 2. (V/ : / > : (X wvr 7)' = X'' wvr F''). 



Proof Proof by induction over /. 
Base step (/ = 0). 

{X WVR y)" X WVR y 
= x° WVR y"* 

= X''o WVR Y'o 



AxiomlH 1 
Axiom|2l 1 
Lemma [T] 



Induction step (i = k+l). 



= NEXT {{X WVRF)*^) 
= NEXT (X''* WVRy* ) 

= NEXT (if firstF'* thenX'* fbyX'*+' wvrJ"'* 

elseX'*+i wvRyt+i) 
= NEXT (if thenX'* fbyX''*+' wvrF'^+i 



+1 



elseX''*+' WVR 



= NEXT (X''* FBYX'* + 1 WVRy'* + ') 
= X''*+1 WVRy^+l 



Axiom 1214 
Ind. Hyp. 
Defn.Ell 

Axiom |2] 3 

Axiom |2] 7 
Axiom|2l5 
Lemma [T] 



Hence, (V/ : / > : (X wvr Y)' = X'' wvr V' 



□ 



Lemma 3. (V/ : / > ~1 : (Vj : r,- < ,/ < r;+i : [U]j = ri+i)). 



Proof Let / > — L Proof by downwards induction over j. Note that r, < r;+i . 
Base step (j ^ n+i). 



[U]rf^^ = [if Y then # else next Defn.|4l4.2 

= if [Y]r^^^ then [#],-,.^, else [next Axiom[T]9 

= [#]r,^i ' ' ' Axiom[T]7 

= r,+i Prop, mi 

Induction step (j = k—l, j > r,). 

[J/]^,_i = [if y then # else next t/]^_i Defn.|4]4.2 

= if [Y]k^i then [#]<-_! else [next U]k-i Axiom[T]9 

= [next U]k^i Axiom[T]8 

= [t/]^ Axiom[I]4 

= n+i Ind. Hyp. 

Hence, (V/ : / > - 1 : (Vy : r,_i < j < n : [f/]; = n+i)). □ 



Lemma 4. (V/ : / > : [r]; = n)- 



Proof Proof by induction over / . 
Base step (/ = 0). 



[T]o = [U fhy U ® {T + 1)]q Defn.|4]4.1 

= [U]o Axiom[I]5 

= ro Lemma[3] 

Induction step (i = k+l). 

[T]k+i = [f/fbyf/Q(r + l)]^+i Defn.|4]4.1 

^[U®{T+l)]k Axiom[I]6 

= [U][T+i], Prop.[I]2 

= [U][T],+i Axiom[I]2 

= [U]r,+i Ind. Hyp. 

= r^-^i Lemma[3] 

Hence, (V/:/>0: [r],- = ri). □ 



Proposition 5. X wvr Y wvr F. 



Proof 



[X wvr y],- = [X T]i Defn. 4.4 

= Prop.[I]2 

= LemmalU 

= [X''']o Axiom[I]2 

= [X''' FBY X'''+^ WVR Axiom[I]6 

= [if [Y]r, thenX''- fbyX'"'+i wvRy'"'+^ Axiom|2]7 

' elseX'''+i wvrF'''+1]o 

= [if FIRST F'"' thenX'i fbyX'"'+' wvRy'+' Axiom|2]3 

elseX'''+i WVR 7'"'+% 

= [X*"' wvRy'lo Defn.|2]l 

= [(XwvrF)']o Lemnia|2] 

= [X wvrF]; Axiom|2]2 

HenceX wvr F =X wvrF. □ 



Proposition 6. X slsslY = X asaY. 



Proof 

Xasar = first (X wvr r) Defn.|4]5 

= first {X WVR y) Prop.|5] 

= FIRST (XwvrF) Prop.|2] 

^XasaY Defn.|2]2 

Hence X asaF =X ASA y. □ 



Lemma 5. (V/ : / > : (X upon F)' = xl^l- upon F') 



Proof Proof by induction over /. 
Base step (/ = 0). 

(X UPON y)" = X UPON r 



= UPON 

^ j^[Ofby...]o uporjyo 
= x['^lo uponF" 



Induction step (/ = ^ + 1). 

{X UPON Yf+^ : 



NEXT ((X UPON F)*^) 
NEXT (Xl^'l* UPON y 
if ( FIRST Y'^) 

tlien(x["'l*+i uponF'^+I) 
else(X[**'l* UPON 7*^+1) 

if [y]k 

then UPON 7*^+1) 

else(X["'l* UPON 7*^+1) 
(•j^(if [F]j. then [w]^+i else [w]^) 

UPON 

^["'l^+i upon7''+' 



Axiom|2l 1 
Axiom|2ll 
Defn.|2l3 
Defn.|4l6.1 



Axiom|2]4 
Ind. Hyp. 
Defn.|2]3 and 
Axiom |2] 5 

Axiom|2]4 
Defn.|4]6.1 

Substit. 

Defn.|4]6.1 



Hence, (V; : / > : (X upon Yj = X^^^' upon 7') 



□ 



Proposition 7. X upon 7 = X upon 7. 



Proo/ Let ! > 0. Then 



[X upon 7], = [X (§ IV],- Defn.|4]6 

= [X][w], Prop.[I]2 

= [^["'I'io Axiom|2]2 

= [Xl*^!' FBY ...]o Axiom[I]5 

= [Xl"'!' upon7']o Defn.[2]3 

— \X UPON Y]i Lemma|5] 

Hence X upon7 =X upon 7. □ 



Now that the corresponding definitions are shown to be equivalent, we can generaUze and head off in the negative 
direction as well: 

Definition 6 

(1) prevX =X @{#-\) 

(2) X fby7 = if#<0 thenX elseY @{#- 1) 



B Summary of the Operators' Examples 



Here we illustrate a few basic examples of application of the Forensic Lucid operators (both, classical Lucid and the 
newly introduced operators). Assume we have two bounded (between bod and eod) streams X and Y of ten elements. 
The X stream is just an ordered sequence of natural numbers between 1 and 10. If queried for values below 1 an 
beginning-of-data (bod) marker would be returned; similarly if queried beyond 10, the end-of-data marker (eod) is 
returned. The Y stream is a sequence of ten truth values (can be replaced with for "false" and 1 for "true"). The 
operators applied to these streams may return bounded or unbounded streams of the same or different length than 
the original depending on the definition of a particular operator. Also assume the current dimension index is 0. The 
resulting table showing the application of the classical and the new operators is in Table [T| 
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Table 1. Example of Application of Forensic Lucid Operators to Bounded Streams 



